[Chapter6] HTTP의 기본

2024년 12월 16일

웹을 지탱하는 기술을 공부하며 정리한 글입니다.
틀린 부분은 지적해주시면 감사드리겠습니다 😀

HTTP

HTTP는 TCP/IP를 베이스로한 프로토콜이다. TCP(Transmission Control Protocol)과 IP(Internet Protocol)는 인터넷의 토대를 구성하는 중요한 네트워크 프로토콜이다.

TCP/IP

인터넷의 네트워크 프로토콜은 다음 표와 같은 계층 구조를 가지고 있는데, 각 계층별로 추상화하여 구현하면, 하위 계층의 구체적인 사항에 좌우되지 않고, 상위 계층을 구현할 수 있다.

계층	요소
애플리케이션 계층	HTTP, NTP, SSH, SMTP, DNS
트랜스포트 계층	UDP, TCP
인터넷 계층	IP
네트워크 인터페이스 계층	이더넷

네트워크 인터페이스 계층

네트워크 인터페이스 계층은 물리적인 케이블이나 네트워크 어댑터에 해당한다.
예를 들어, 동선인지 광케이블인지를 의미하는 것이다.

인터넷 계층

네트워크에서 데이터를 실제로 주고 받는 것을 의미한다.
IP에서는 데이터의 기본 통신 단위를 패킷이라 부른다.
지정한 IP 어드레스와 패킷 단위로 데이터를 주고 받으며, 통신한다.

트랜스포트(전송) 계층

데이터의 무결성을 보증하는 역할을 한다.
TCP는 목적지에 대해서 커넥션을 연결하고, 데이터의 누락을 체크하고, 데이터의 도달을 보증한다.
커넥션에서 전송하는 데이터가 어느 애플리케이션으로 전달되는지는 포트 번호로 정해진다.
디폴트는 80이며, 1~65535까지의 수치를 사용한다.

애플리케이션(응용) 계층

구체적인 인터넷 애플리케이션, 메일, DNS, HTTP를 실현하는 계층이다.
TCP 기반의 애플리케이션을 만들 때, 소켓(socket)을 일반적으로 사용한다.
HTTP 서버와 브라우저는 소켓을 이용하여 구분하는데, 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속, 송신, 수신, 절단 등의 기능을 갖추고 있다.

HTTP의 버전

HTTP 0.9

HTTP 0.9는 사실상 버너스 리가 웹을 발명했을 때, 사용하던 프로토콜을 의미하는데, 스펙 시트가 따로 존재하진 않는다. 또한, HTTP 메소드는 GET 뿐이었고, 헤더도 존재하지 않았다.

HTTP 1.0

HTTP 1.0에 들어서는 헤더가 도입되었으며, GET 이외의 메소드들이 추가되었다. 1993년에 IETF(Internet Engineering Task Force)에서 표준화가 이루어진 최초의 버전이며, 1996년에 최종 버전인 RFC 1945가 공개되었다.

HTTP 1.1

HTTP 1.1은 1997년 RFC 2068로서 책정되었다. 이후 개정을 거쳐 1999년에 RFC 2616이 발행되었다. 이것이 현재까지 쓰이고 있는 HTTP 1.1의 스펙이다. HTTP 1.0의 기능에 채널 전송, Accept 헤더에 의한 콘텐츠 네고시에이션, 캐시 컨트롤, 지속적 연결 등에 대한 기능이 추가되었다.

HTTP 구조

HTTP의 구조는 다음과 같은 구조를 갖고 있다.

클라이언트/서버
요청/응답
HTTP 메시지
HTTP 스테이트리스성

클라이언트/서버

웹은 아키텍처 스타일로 클라이언트/서버를 채용하고 있다. 클라이언트(웹 브라우저)가 정보를 제공하는 서버에 접속하여, 각종 요청을 보내고 응답을 받는 구조이다.

요청/응답

위에서 본 내용과 같이 클라이언트가 보낸 요청을 서버에서 처리하고 응답을 돌려주는데, 이런 프로토콜을 가리켜 요청/응답형(Reqeust-Response Style) 프로토콜이라고 부른다.

클라이언트에서 서버에 요청을 보낼 때 다음과 같은 일이 일어난다.

요청 메시지 구축
요청 메시지 송신
(응답이 돌아올 때까지 대기)
응답 메시지 수신
응답 메시지 해석
클라이언트의 목적을 달성하기 위한 처리

서버에서는 다음과 같은 일이 일어난다.

(요청이 들어오길 대기)
요청 메시지 수신
요청 메시지 해석
적절한 애플리케이션 프로그램으로 처리 위임
애플리케이션 프로그램 결과 취득
응답 메시지 구축
응답 메시지 송신

HTTP 메시지

요청 메시지와 응답 메시지를 합하여 HTTP 메시지라고 부른다.

요청 메시지

GET /test HTTP/1.1
Host: example.com

요청 라인

HTTP 메소드, 요청 URI, 프로토콜 버전으로 구성된다.
요청 URI를 절대 경로를 사용한 경우 Host는 생략할 수 있다.

헤더

헤더는 메시지의 메타 데이터가 들어간다.
하나의 메세지는 복수의 헤더를 가질 수 있다.

메타 데이터란, 데이터를 기술하는 데이터, 데이터에 대한 데이터를 말한다. 메타라는 것은 어떤 대상에 대해 고차원 것을 나타내는 접두어로 사용된다.

이후에는 POST 요청과 같은 경우에 사용되는 바디가 이어진다. 메시지를 나타내는 본질적인 정보가 들어오며, 리소스를 새로 작성하거나 갱신할 때는 리소스의 표현 자체가 들어간다.

응답 메시지

HTTP/1.1 200 OK
Content-Type: appilcation/xhtml+xml; charset=utf-8
<html...>
</html>

스테이터스 라인

프로토콜 버전, 스테이터스 코드, 텍스트 구문으로 구성된다.
요청의 결과를 프로그램으로 처리 가능한 수치 코드를 표현한다.

헤더

Content-Type 헤더에서 HTML의 미디어 타입과 문자 인코딩을 지정한다.

바디

헤더와 바디는 빈 줄로 구분된다.

HTTP의 스테이트리스성

스테이트리스란, 서버가 클라이언트의 애플리케이션 상태를 보존하지 않는다는 제약을 의미한다. 애플리케이션의 상태란 말이 모호하기 때문에 다음 예를 통해 확인해보자.

# 스테이트풀의 대화
손님 : 햄버거 세트 주세요.
점원 : 사이드 메뉴는요?
손님 : 포테이토요
점원 : 음료는 무엇으로 드릴까요?
손님 : 콜라요

# 스테이트리스의 대화
손님 : 햄버거 세트 주세요.
점원 : 사이드 메뉴는요?
손님 : 햄버거 세트, 포테이토요
점원 : 음료는 무엇으로 드릴까요?
손님 : 햄버거 세트, 포테이토, 콜라요

스테이트풀한 대화는 간결하지만, 스테이트리스는 장황한 것을 알 수 있다. 이렇듯, 스테이트풀하다는 것은 이전의 행동을 기억하는 것인데, HTTP에서는 이를 애플리케이션 상태 즉, 세션 상태라고 부른다.

우리가 로그인을 하고, 로그아웃을 할 때까지의 조작을 모아 세션이라고 하는데, 이 일련의 조작 중의 상태를 애플리케이션 상태를 의미하는 것이다.

만약, 100대 까지의 클라이언트를 처리할 수 있는 서버가 있다고 가정할 때, 101대 이상의 클라이언트를 처리하기 위해서는 2대 이상의 서버가 필요하게 된다. 즉, 1번으로 접속한 사람이 1번 서버에 들어갔다가, 이후에는 101번 째로 들어와 2번 서버에 들어갈 수 있는 것이다.

이럴 경우, 클라이언트가 1번 서버와 2번 서버 모두 동일하게 사용할 수 있어야 하기 때문에, 데이터를 제대로 동기화 시켜야 한다. 하지만 이에 대한 오버헤드는 무시할 수 없기 때문에, 스테이트풀한 아키텍처는 규모를 확장하기 어렵게 된다.

반면, 스테이트리스는 요청이 올 때마다 필요한 모든 정보를 한 번에 받는다. 이를 자기 기술적 메시지(Self Descriptive Message)라고 한다. 서버가 클라이언트의 애플리케이션 상태를 기억하는 대신, 클라이언트는 모든 요청을 자기 기술적 메시지 형태로 송신한다. 즉, 들어오는 요청을 처리하는데에만 집중하면 된다.

이런 스테이트리스도 단점이 있다. 모든 정보를 한 번에 받기 때문에, 송신할 데이터의 양도 많아지고, 부하가 걸리는 처리를 반복할 수도 있다. 때문에 네트워크 대역을 낭비할 수 있다는 단점이 있다.

Jwhy